Re: Request for discussion.
Casper Dik (casper@fwi.uva.nl)
Tue, 07 Feb 1995 10:14:54 +0100
>> By the same token, many people dont run /bin/login suid root. So in this
>> instance, you're just swapping one privileged program for another? Is
>> login better to have running as root than telnetd? I can think of more
>> published holes in login.
>
>Login inherently has to be run as root. It doesn't inherently have to
>be suid though. If you dont want normal users running login from the
>command line you can put an ACL on the file (if you have support for
>that in your kernel) or you can have the program check the uid of
>the invoking process itself (basically an ACL built into the program).
We don't run login set-uid and have done so for quite some time.
You need to make sure that login checks the return values of setuid()
though, or you'll have surprising effects. Login is usually started
by root (from getty, ttymon, telnetd, rlogind, etc) and only seldom
by normal users (login command in all shells).
We have not noticed any adverse side effect of this change, the positive
effects are:
- one les set-uid program
- impossible to remove you remote host entry from utmp/wtmp
- impossible to hide who you are with:
(login user) [subshell] follwoed by logout.
>> Also what about changing ownership/permissions of your pty (on BSD based
>> pty systems) on login/logout, and writing wtmp records on logout?
>
>Ah. This is the reason. This is something I wanted to see fixed a
>long time ago. There are several ways of handling this. The one
>I like is having a program that will write the utmp and chown the
>pty all in one step for you. This program would run at a "utmp"
>priveledge level.
login already the tty (the daemon doesn't know who will log in).
Daemons do manage the utmp entries. Solaris 2.4 already has the
program to write utmp and wtmp.
Casper